一個系統或者是功能會源自於需求的發生，接著舉個例子從使用者出發的角度來探討怎麼轉換成具體的開發資訊。
下述的例子不預設是什麼產業，並且先以簡單平白的敘述逐步解析
目前的內部的工作流程大部分是人工作業，紀錄的方式有一部分要是透過手寫，也因此時間一長用紙本紀錄的資料變得難以整理。部門的老闆也察覺到這個狀況，於是希望我們希望可以將紙本的資訊存取到電腦內，另外也希望有一些重覆性的工作有沒有什麼服務或是工具協助。
當聽完這些需求後第一件事情會先把幾個關鍵字條列出來，接著就來從關鍵字再進一步分析
首先手寫的情況對應的解決方式就是直接資料寫到電腦上(有點廢話)，但手寫這件事情可以進一步確認幾個情況，例如這件事情已經持續多久了、先前是否有嘗試使用可以改善手寫情況的措施、有沒有一些原因所以到現在只能手寫等等。
管理上的問題可以先確認是否已經有管理的規則，如果沒有的話就可以與需求者討論後續想要管理的方式(如果使用者還是沒有想法可以提出幾個可行方式)。
重覆性的工作流程可以與人工作業的情況一起納入檢視，並且依照上面兩個可以對應解決的方法(若能成功數位化)，就可以尋找目前市面上的一些自動化的工具和解決方案(細節會再後續幾天獨立一篇補充)。
如果內心有上述的一些延伸疑問可以再次與提出的需求者確認，因為如果有一些回饋的資訊，在下一個步驟的初步解法會比較更貼近後續的選擇。
前面的部分都是單從文字的敘述去思考對應的可行方案，但還有一些外在的因素也要一起納入考量
相信一些工程師或者是協助處理需求的開發者，在接獲到新需求的當下手邊也有其他的事情也正在處理，也因此替使用者想到相關解法的同時，也要回頭看看自己提出的這些解法在執行的時候能不能如期。
這個情況從使用者的角度說明，在情境敘述的時候提到部門的老闆也察覺到這個狀況，所以除了與需求者詢問希望能夠在什麼時間完成外，也可以再透過信件或者是討論需求的會議，邀請該部門的主管確認一下其他細節以及需要完成時間點。
總結今天的整個內容主要是想透過一個情境發想，接著去延伸思考這一個需求提出的當下可以再留意哪一些細節，對於一個階段性提出的解決方法相對來說，更加全面的確保想要解決的方向沒有偏離太多。
沒有最完美的解決方法，只有最適合的解決方法
iThome鐵人賽
看影片追技術